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Network Meeting Report 


This is a report on a series of three Network Working Group meetings at 
the Fall Joint Computer Conference, November 16, 17 and 18 in Houston, 

Texas. The meeting will be lumped together and ideas may or may not be 
identified as to their originator. The meetings were chaired by Steve 

Crocker. 


The meetings began with a listing of topics of concern. 


1) A site or group should be designated as protocol testers. As NCP’s 
are implemented they should be subjected to comprehensive testing by 
an independent group. 


2) The Host-Host protocol needs reworking in several areas: error 
control, overload conditions, allocation of resources, status 
information, and system crash problems. 


3) The immediate need for specification of TELNET, the third level 
program which allows people to pass through their local hosts and use 
remote hosts. TELNET must provide facilities to log in at a distant 
site, run programs, transmit files, and call for help. This call for 
help is likely to mean getting a systems programmer at the remote 
site "taking control" of the user console. 


4) The documentation of systems on the network must become available to 
all sites. This is to be done by the NIC with the cooperation of the 
other sites. Particularly useful will be on-line documentation. It 
is suggested that each site have an identical hard copy device (e.g. 
a line printer) suitable for reproducing documents. 


5) The use of graphics consoles on the network will require a graphics 
protocol. People interested in this problem should write position 
papers on such a protocol. A meeting may be held between the authors 
of such papers if sufficient interest develops. The papers should be 
distributed as NWG/RFC’s before 1 January 71. 


6) Some sites must account for use of their computer resources, thus 
there must be some network accounting scheme. Sites can be 
categorized as Research Centers vs. Service Centers. The Service 
centers tend to have big machines, lots of users, and accounting 
problems; while the Research Centers tend to have specialized 
hardware, a small number of users, and no accounting at all. 
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7) Some people are interested in the network as an object of study. In 
particular UCLA-Computer Science, and BBN wish to perform 
measurements on the network. Is it appropriate to ask the NCP to 


keep statistics? 
After this opening some discussion followed. 


It was generally felt that changes to the protocol should be made in 
bunches and at about six-month intervals rather than a continuous stream 
of small changes. Also that a lead time of three months was not over 
optimistic. The proposed change to the IMP-Host protocol to get rid of 
marking was generally approved but it will not be implemented for some 
time since casual changes to the protocol are undesirable. Tom 

O’ Sullivan suggested that perhaps new and old protocols could work 
together, that is the new protocol would support the old one as well as 
provide better mechanisms where possible. Steve Crocker suggested that 
a new protocol might be developed as a private experimental protocol 
between two or three sites. 


It was stressed that it is necessary that the network be used to gain 
experience, and that we should get teletype-like console use of remote 
systems going before we get too involved in graphics. Perhaps the 
graphics protocol should be developed by a different set of people. The 
scheduling of a graphics protocol meeting was thus discouraged, but 


papers should still be written. Strong feelings were expressed in 
favour of first developing use of remote subsystems and file 
transmission instead of worrying about graphics at this stage. It was 


suggested that development of protocols at the higher levels be driven 
by applications. 


Documentation will be a major concern for network users. Several people 
mentioned that users at their sites have already begun to inquire about 
the network. As Eric Harslem put it "What does the ARPA Network have to 
offer?" Some sites (Multics, SRI) keep system documentation on-line. 

It was suggested that the trillion bit store be used to keep on-line 
documentation of all systems. 


At this point Doug Engelbart gave a presentation on the Network 
Information Center (NIC). The goals or services of NIC have not been 
well defined by anyone and have been left up to NIC to define. NIC has 
decided that one urgent task is to make information about the network 
and the host systems on the network available to users of the network. 
Doug has found that some people feel threatened by the revelation of 
their documentation inadequacy. Doug’s project at SRI has built up a 
system that allows the user to create catalogs and indices into a 
collection of information. The system has a master catalog of all 
information files. Each user may have a number of private (or shared) 
catalogs. The system provides a means of examining on-line the catalogs 
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and amending them. The system also provides a means to examine any 
information file which happens to be on-line and for creating new 
information files on-line. 


Several problems will delay the NIC from coming on the network. One of 
these is the switch from the XDS-940 to the PDP-10 (TENEX). The switch 
is being made because the 940 system is inadequate to handle the 
anticipated load. At first it was planned to offer service on the 940 
and switch to the 10 when it came up, but too much effort would be 
required for a very small payoff. 


Doug explained the working of the Network Dialoge System. At each site 
there is a communication agent and a technical liaison officer. The 
agents will be trained by NIC to use the facilities of NIC to get 
information about the Network and other sites. The agents will acquire 
from NIC documents of interest to users at the local site, be able to 
contact NIC at a toll free number, and should have an on-line console 
into the network (and therefore NIC). Thus the Network Dialoge System 
is a network of people (the agents). 


Steve Crocker then brought us up to date on the status of the network. 
He drew a picture of what is connected and what is proposed. He 
discussed the level of implementation at various sites. Eric Harslem 
mentioned that RAND and UCSB had conducted tests of their NCP 
implementations last week (10 Nov 70) and that things worked well. 


Frank Heart announced that BBN was planning the development of a 
"Terminal" IMP. The Terminal IMP would support some large number of a 
wide range of consoles as well as provide the normal IMP functions. 


At this point we broke and scheduled to reconvene Tuesday morning. 


The Tuesday meeting started with Doug giving another pass at explaining 
the SRI system at a more detailed level. The basic thing to deal with 
is the collection. The user can query over the collection or over sub 
collections. The user can obtain bibliographic references of three 
kinds: a) full references, b) first line, c) author indexed. 
Information files of the collection may be on-line, in tape libraries, 
or only in hard copy. It is suggested that much data could be kept at 
other network sites, for example the trillion bit store and before that 
perhaps on disk at UCSB. If files are kept at other sites then the 
system must be able to retrieve them automatically when they are 
requested. The subsystem to be used is called TODAS. TODAS is an 
evolving program and the documentation of TODAS is inadequate. In 
TODAS, file are organized hierarchically, each paragraph is numbered, 
and it is possible to do context analysis on the text. 
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Doug then mentioned some things about the console interaction. This 
raised a question about half vs. full duplex and line oriented vs. 
character oriented systems. The remainder of the meeting revolved 
around this issue. 


I shall try to define the terms as I understand them for purpose of 
clarity in the following. Half duplex is the situation where the 
console, a peripheral processor or some very low level software, echos 
the character entered. The console can not be used to input data while 
output is in progress. Full duplex is the situation where the character 
typed is echoed by software, and input can be done at the same time as 
output. In line oriented systems the user enters a complete line 
terminated by an extra sensitive and of line character (e.g. carriage 
return). Often the keyboard is then locked until after the next output. 
In character oriented systems each character the user enters is 
interpreted by software before it is echoed and the echo may be 
different from the character entered. In particular after a few 
character the software may guess what the user wants and complete the 
line for him. The following chart will be used for clarity. 


Half Duplex Full Duplex 


| 

Character | 
Oriented typel | type2 

| 

Line | 
Oriented type3 | type4 

| 

| 


It was discovered that many people don’t really know where their own 
systems fit in this chart and are very vague about what it means to 
interact with a system in a different than their own. Doug stated that 
NIC has a system of type 2 but would try to provide service to all types 
of systems. The following table shows systems with their interaction 
type and categorization as to Research vs. Service Center. 
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System Interaction Type Categorization 
UCLA - Sigma-7 2 - char, full Research 

UCLA - 360/91 3 - line, half Service 

MIT - Multics 3: > Jine, half Service 

SDC 3 - line, half ? 

RAND 3 or 4 - line, ? ? 

SRI 2 - char, full ? 


Al Vezza promised to study this problem and to circulate his results as 
an NWG/RFC. It was pointed out that line oriented systems usually allow 
line editing of the form "delete last character" (back space) and 
"delete line", however this feature does not alter their classification 
as to interaction type. Concern arose over what do line oriented 
systems expect to receive from the network for a connection acting as 
console input to a subsystem. Steve Crocker made the suggestion that 
when using a line oriented system transmission be in lines. More 
precisely that transmission be in strings of the following form. 


nel 62) 2 .'en 
where 1 <= n <= 120 (n is eight bits) 
and if ci is an "end of line" character then i = n 


This suggestion was not immediately accepted and some discussion took 
place regarding the significance of Host-Imp-Host message boundaries. 
Doug brought up file transmission and the problem of finding the end of 
the file, which provoked more discussion. At this point the meeting 
broke up with a third session scheduled for 8:00 p.m. Wednesday evening. 


The Wednesday meeting began with the suggestion that at future xJCC’s 
there be an official ARPA Network hotel with a block of rooms on one 
floor and a nearby meeting room for networkers. This suggestion was 
favored by all. 


Steve Crocker asked how people felt about these meetings. The general 
feeling was that the meetings were very useful and should occur about 3 
months apart. Al Vezza pointed out that meetings this size (15 - 30 
people) are good for bringing up problems but not for putting them down. 
Steve proposed that 3 or 4 people be designated to solve particular 
problems. Al responded that 3 people can’t legislate. That any such 
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solution must be considered in the same way as a proposal by an 
individual. 


Steve persuaded Peggy Karp to act as NWG/RFC editor. This is a job 
independent of cataloging RFC’s or assigning numbers (functions now 
performed by NIC). The RFC editor will only categorize RFC as "hot 
issues", current, out of date, or superseded. 


The subject of Logger protocol -- that is, how to get the first 
connection -- needs to be officially defined. NWG/RFC #66 suggests one 
way. Eric Harslem will revise this and send it out as proposed official 
protocol. Ed Myer will also send out a proposal. 


Steve then opened up discussion of the topics of the previous meeting by 
suggesting we talk about the following: Message boundaries, half duplex 


vs. ull duplex, line oriented vs. character oriented, file 
transmission, byte counts in messages, byte sizes and transactional 
units. It was proposed that transactions on the command link (i.e. 


between NCP’s) be always in multiples of eight bits. This mean that the 
length field in the ECO, ERP, and ERR commands will always have three 


low order zeroes. This was approved. Steve then proposed that 
connections could be established with a declared byte size and a maximum 
record length in bytes. Transactional units on this type of connection 


would be of the form 
nel G2Ae3 9580 en 


where 0 <= n <= max record length 


if n = 0 then the transactional unit acts like a semaphore. Steve 
suggested that we should look into the theory of information exchange, 
particularly along the lines of Richard Kaline (NWG/RFC #60). Perhaps 


for each information unit sent there should be some status response. 


The next question was on file transmission. In particular, how do you 
find the end? Frank Heart suggested that with each portion there be a 
flag indicating "this is not the end" until in the last portion the flag 
is switched to indicate "this is the end". Eric Harslem suggested that 
each portion should have an "opcode" field, a length field, and the text 
which is length bits (bytes?) long. This appears to be like the data 
types proposed at the Lincoln Lab meeting last spring. Ed Myer proposed 
that two connections be used, one for the file transmission and the 
other to control it. The file control connection would specify the data 
connection and indicate that transmission as about to start. After the 
sender had completed the file transmission he would send on the file 
control link the total number of bits sent. The receiver would then 
know how many bits to receive and exactly where the end of the file 
should be. Bob Metcalfe was concerned that some of the proposals mixed 
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control information with data and felt that perhaps this mixing should 
be avoided. 


Steve asked if anybody could suggest an advisor we might talk about 
these problems. Bob Metcalfe suggested Anatol Holt. Bob Sundberg 
suggested George Mealy. Eric Harslem and Peggy Karp suggested that 
people who worked on the COIN System might be helpful. Frank Heart 
suggested that no one has solved these problems. 


Steve proposed that Service Centers offer line oriented interaction with 
no echoing of the input. Any simple editing (e.g. back space) would be 
done at the using site. Ed Meyer suggested that there be official 
protocols for both line oriented and character oriented interaction. 
Steve promised to write a NWG/RFC clarifying the issues and laying out 
the arguments on full transactions, byte counts, and accumulating data 
on the receive side. 


It was felt that these were hard problems that needed more thought. 
Thus the meeting was adjourned with the request that people circulate 
any ideas or proposals as NWG/RFC’s. Ed Myer took notes and agreed to 
also prepare a NWG/RFC summarizing these meetings. 
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Network Meeting Attendance List 16 - 18 Nov. 70 Houston 


Name Site Sessions 
21. Tijaart Schipper UCLA - CCN I 
22. Michael Sher Illinois - CAC 1 
23. Bob Sundberg Harvard 1273 
24. Hal Van Zoeren CMU 1,2;3 
25. Albert Vezza MIT - DM 1,273 
26. Alfred Vorhaus MITRE 1 
27. Clark Weissman SDC 1 


[ This RFC was put into machine readable form for entry ] 
[ into the online RFC archives by Gottfried Janik 02/98 ] 
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